📜 Description

Fix race condition in manual iOS did keyboard events introduced in #1161.

When navigating between screens, keyboard events may arrive in non-linear order (willHide -> didShow -> didHide). The last delayed didHide could incorrectly win and reset keyboard height to 0, even when keyboard is already visible on the new screen.

This change keeps the manual did strategy from #1161, but validates actual keyboard state at delayed execution time.

💡 Motivation and Context

After upgrading to 1.20.6, some navigation flows started producing incorrect keyboard offset on the next screen:

• keyboard is visible
• but computed offset is 0
• content goes under keyboard

Root cause: delayed DispatchWorkItem tasks may execute out of logical order during responder/navigation transitions.

This PR prevents stale delayed events from overriding current keyboard state.

Problem Statement (clear event order issue)

When navigating between screens, keyboard events can arrive in an invalid order:

1. keyboard hide
2. keyboard show end
3. keyboard hide end

As a result, the last processed event is hide, keyboard height is set to 0, and offset is recalculated to 0.
On the next screen, keyboard is visible, but bottom inset is not applied, so content goes under the keyboard.

Reproduction

Keyboard.dismiss();

await wait(400);

// navigate to screen with auto-focus input
navigation.navigate(...);

Expected:

• final keyboard state should match visible keyboard (height > 0)
• bottom offset should remain applied on the destination screen

Actual before fix:

• delayed stale didHide may run last
• keyboard height/offset becomes 0 while keyboard is still visible

📢 Changelog

iOS

• validate delayed did event against current keyboard visibility before emitting didShow/didHide
• add stale-task guard (keyboardDidEventID) so old delayed tasks cannot override newer state
• cancel pending delayed did tasks and clean up watchers/KVO on unmount
• keep manual did dispatch approach from fix: manual did events #1161 (no rollback to system keyboardDid*)

🤔 How Has This Been Tested?

Tested manually on iOS navigation scenario with focused input:

1. Open screen A with focused input (keyboard visible).
2. Navigate quickly to screen B where input becomes focused.
3. Reproduce event interleaving where hide/show callbacks race.
4. Verify final state:
   • keyboard remains visible
   • keyboardDidHide does not incorrectly win
   • keyboard height/offset is not reset to 0
   • content stays above keyboard on the new screen

Also verified unmount path does not emit late delayed did events from removed screen observer.

📸 Screenshots (if appropriate):

Before

After

📝 Checklist

• CI successfully passed
• I added new mocks and corresponding unit-tests if library API was changed